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METHODS and SYSTEMS FOR 
PERFORMING USAGE BASED 

BILLING 

Background of Invention 

[0001] This invention relates generally to usage based billing products and services 

and more particularly, to timely and accurate electronic transmission, management 
and corroboration of usage based billing and accounting information between 
multiple parties. 

[0002] Manufacturers and dealers sometimes provide equipment to end users and 
charge the end users a fee based on the extent to which the equipment is used. 
Such an arrangement, sometimes referred to as usage based billing, is 
advantageous for an end user since the expense of purchasing the equipment is 
avoided and service and maintenance of the equipment is usually included in the 
fee. 

[0003] For example, office technology dealers sometimes provide a customer with 

equipment for business use and the customer is charged based on the customer's 
use of the equipment. With photocopiers, for example, the customer is billed 
based on the number of photocopies produced by the machines during the billing 
period. As an example, a customer may be billed $500 per month for a pre-set 
number of copies. The cost of equipment, service and maintenance is usually 
included in such payment. If the customer makes more than the pre-set number of 
copies in any given month, then the customer is also billed a per copy charge for 
each copy made in excess of the pre-set number of copies to cover the 
incremental cost of service and maintenance. 
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[0004] With respect to equipment supplied to customers on a usage based billing 

arrangement, the dealer often may secure financing from a financial institution. For 
example, the usage based lease entered into with the customer, the leased 
equipment and the equipment rental portion of each payment may be assigned to 
the financial institution. While the dealer collects or otherwise obtains information 
related to the monthly usage of the equipment, the financial institution is usually 
responsible for billing and collecting the payments from the customer. The dealer 
typically remains responsible for service and maintenance, and the cost of such 
service and maintenance is usually included in the amount billed by the financial 
institution to the customer. Therefore, the financial institution not only bills and 
collects from the customer, but also remits to the dealer that portion of each 
payment attributable to service and maintenance and excess usage charges. 

[0005] To accurately determine the amount to be billed to a customer, information 

relating to the extent to which the equipment was used during the billing period is 
obtained. For photocopiers, for example, a meter coupled to each photocopier 
counts the number of photocopies made at each machine. The meter data is then 
collected and supplied to, for example, the dealer. If a dealer has many customers, 
and each customer has many photocopiers, simply collecting the meter data for 
each photocopier is a time consuming and tedious task. 

[0006] Once the meter data is collected, the dealer then transmits the data to the 

financial institution. Reviewing the meter data, calculating the amount due for use 
of each photocopier, consolidating the data for each customer, and then sending a 
bill to each customer also is time consuming and tedious. 

[0007] Further, since the amount billed for each photocopier is based on the number 
of copies made at each photocopier, the accuracy of the bills is dependent upon 
ensuring that the meter data has been correctly collected, entered, and processed. 
With multiple photocopiers and multiple customers, ensuring that the meter data 
has been correctly collected, entered, and processed is time consuming and 
tedious. 

[0008] Qnce a customer has received a proper bill and submits payment to the 



Page2 of 27 



financial institution, the financial institution then remits the agreed upon portion of 
the payment to the servicing dealer to cover the dealer's service and maintenance 
charges. Both the dealer and the financial institution also apply the money received 
to their respective open accounts receivables. Due to the high volume of data, the 
complexity associated with having the meter data collected by the dealer and relied 
upon by the financial institution to correctly bill and collect payments due and 
payable by the customerln a timely manner, and the combination of the service 
and maintenance charges with the excess usage charges, simply ensuring that 
each dealer receives the proper payment and that the payments are applied to the 
proper accounts is a complex task. Such complexity adds to the administrative cost 
of usage based billing arrangements. 

Summary of Invention 

[0009] In one aspect, a method for operating a computer to facilitate receipt and 
validation of meter data is described. An exemplary embodiment of the method 
includes the steps of receiving meter data related to equipment usage, applying 
validation rules to the meter data, and generating an error report identifying meter 
data that violates at least one of the validation rules. 

[001 0] In another aspect, a method for operating a computer to facilitate correction of 
meter data is described. An exemplary embodiment of the method includes the 
steps of receiving meter data and storing the data in a database, applying 
validation rules to the received meter data, associating an error identifier with each 
data entry that violates a validation rule, and storing, in the database, the error 
identifier and associated data entry. The method further includes, for example, 
generating a meter correction report identifying the data that violates a validation 
rule and providing that a dealer can enter updates, or corrections, directly in the 
meter correction report so that the data stored in the database can be corrected 
from the report entries. 

[0011] 

In yet another aspect, a method for operating a computer to facilitate the 
issuance of invoices and reconciling open payables records is described. An 
exemplary embodiment of the method includes the steps of generating invoices 
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related to equipment usage, applying received payment to open invoices, and 
creating a payables data file. The payables data file includes at least one of check 
number, check amount, payment detail by asset, service payment breakdown by 
base service and overage charges, dealer invoice number and customer name. 

[0012] In still another aspect, a database for use in a usage based billing system is 

described. The database, in an exemplary embodiment, includes an export data file 
containing at least one of asset serial number, model number, meter reading date, 
an invoice number, amount of receivable, customer name, coverage begin date, 
coverage end date, and service credits. The database further includes a payables 
data file having at least one of check number, check amount, payment detail by 
asset, service payment breakdown by base service and overage charges, dealer 
invoice number, bill to number and customer name. The payables file also includes 
a header record that identifies which data elements should be used by the OMD 
Task 1 Y to match the data in the payables data file to the dealers payable data in 
the OMD software. Validation rules also are contained within the database. 

Brief Description of Drawings 

[001 3] Figure 1 is a block diagram of a network based system. 

[001 4] Figure 2 is a data flow diagram for a meter data process. 

[001 5] Figure 3 is a data flow diagram for another embodiment of a meter data 
process. 

[001 6] Figure 4 is a data flow diagram for payables data process. 

Detailed Description 

[0017] 

Although embodiments of the meter data process and payable data process 
sometimes are described herein in the context of photocopiers, such processes are 
not limited to practice with photocopiers. Such processes can be used in 
connection with many other types of office technology, as well as non-office 
related technology. Therefore, the description of the processes in the context of 
photocopiers is byway of example only and such processes can be utilized in 
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many other contexts as well. 

[001 8] Figure 1 is a block diagram of a network based system 1 0. System 1 0 includes 
server sub-system 1 2 that includes a web server 1 4, an application server 1 6, a 
database server 1 8, a disk memory storage 20, a directory server 22, and a main 
frame 24 coupled via a network 26, which may be a local area network or a wide 
area network. Database server 1 8 incorporates a database such as an Oracle based 
database, commercially available from Oracle Corporation, 500 Oracle Parkway, 
Redwood City, California, 94065. 

[001 9] Multiple work stations 28, such as work stations 30, 32, and 34 are coupled to 
server-subsystem 12 via network 26. Each work station 30, 32, and 34 is, for 
example, a personal computer and multiple functions, as described below in more 
detail, can be performed at each work station 30, 32, and 34. For example, system 
administration, billing initiation and coordination, and error correction tasks can 
be performed at work stations 28. 

[0020] Server sub-system 1 2 also is communicatively coupled to dealers 36 via an ISP 
Internet connection 38. The communication in the exemplary embodiment is 
illustrated as being performed via the Internet, however, any other wide area 
network (WAN) type communication can be utilized in other embodiments, i.e., the 
systems and processes are not limited to being practiced via the Internet. Of 
course, multiple dealers 40 and 42 can communicate with server sub-system 12. 
Each dealer 40 and 42, in the exemplary embodiment, has a server 44 for 
performing meter data administration functions and a personal computer 46 
coupled to server 44. 

[0021] In the exemplary embodiment, server 44 hosts the OMD software commercially 
available from OMD Corporation, 3705 Missouri Boulevard, Jefferson City, Missouri 
651 02. The OMD software performs administrative functions for usage based 
billing applications. In the exemplary embodiment, a dealer 40 can access server 
sub-system 12 via Internet connection 38 and perform tasks as described below in 
detail. Personal computer 46, in the exemplary embodiment, operates a Windows 
based operating system. 
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[0022] Although the processes described below are sometimes described herein in the 
context of system 10, such processes can be practiced using many different 
systems having different architectures and components. Therefore, the processes 
are not limited to practice in connection with system 1 0 and the description below 
is exemplary only. 

[0023] Figure 2 is a block diagram of one embodiment of a meter data process. The 
process steps illustrated in blocks 50 and 52 typically are performed by a dealer, 
and the process steps illustrated in block 54 typically are performed by a financial 
institution that has purchased the equipment lease portion of the contract with the 
end user. The financial institution receives its payments based on usage of the 
equipment by an end user. Of course, if a dealer has not sold or contracted for the 
services identified in block 54, then such processing would be performed by the 
dealer rather than a separate entity. 

[0024] Referring now specifically to Figure 2, meter data is collected by the dealer and 
input into OMD software application residing on server 44. Again, the OMD 
software performs dealer distribution management tasks. Using the OMD software, 
the dealer inputs meter data and runs a task in the OMD software that generates 
an export file containing the meter data. The export file contains meter data, asset 
serial number, model number, meter reading date, an invoice number, an amount 
of the receivables, customer name, coverage begin date, coverage end date, and 
service credits. The dealer then copies the export file from the OMD environment 
into the Windows environment of personal computer 46. 

[0025] 

More specifically, once the export file is copied into computer 44, the dealer 
accesses system 1 0, e.g., via a web site. Access to system 1 0 is controlled, for 
example, using authorized user names and passwords. Once the dealer enters an 
authorized user name and password, the dealer then has access to server sub- 
system 12 and transmits the export file to the Oracle database. The data file 
format is validated by system 1 0 and the data fields are checked for null values. 
Once the data is accepted, a header record is created to identify the file sender and 
number of records. Also, once the data is accepted, the dealer receives 
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confirmation, e.g., via the web site, such as: Your file was successfully transmitted. 
We received XX records in your file. Our Usage Billing System will be processing 
your file. If during that process any errors are encountered, we will contact you. 

[0026] A data validation routine is then executed, e.g., by main frame 24, to validate 
each data record of each transmitted file. The routine uses the following rules to 
validate the data: asset or serial number not found; serial number or serial 
number/model number are not unique; the account is not active; current meter 
date is not a valid date; current meter date is more than 30 days ago; current 
meter date is less than previous meter date; current meter date must be within 2-5 
days of the expected meter date; invalid current meter reading (i.e., not numeric); 
current meter reading less than previous meter reading; dealer provided meter 
credits; calculated overage charges by dealer does not equal preset amount; excess 
amount is greater than $1500; if consolidated account, all assets readings not 
received in file; duplicate readings. Each data record that passes all validation rules 
is then automatically processed in the mainframe system for invoicing the lessee 
for the service payment. 

[0027] More specifically, exemplary validation rules are set forth below. 
[0028] 

Serial Number - not found in mainframeSerial Number duplicate found in 
mainframeMeter Read duplicate meter read found in data fileAccount Schedule 
status not ActiveSerial Number has more than one meter assignedCurrent Meter 
Read Date - invalid data formatCurrent Meter Read Date > current system 
dateCurrent Meter Read Date > 30 days agoCurrent Meter Read Date < previous 
meter read dateCurrent Meter Read Date - not within range of expected next read 
dateCurrent Meter Read < previous meter read or invalid data formatMeter Service 
Credits > OExcess Usage Charge > $1 SOONext Invoice Due Date > 2 months from 
current system dateSerial Number invalid data formatMeter Read duplicate found in 
mainframeConsolidated Meter Account all meter reads not received in data 
fileAccount Schedule duplicate record for the same account scheduleConsolidated 
Meter Account one or more readings in errorExcess Usage Charge - not equal to 
mainframe calculated chargeAccount Schedule The financial institution does not do 
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the billingData records that do not meet any one of the validation rules are 
rejected. The rejected data records and the reason for each failure are printed to an 
Error Report by Dealer. Each rejected data record is to be reviewed to determine if 
the reject was caused by an internal error that is not caused by invalid dealer data. 
For example, validation rules reject any data record when a duplicate serial number 
is found in the system. This validation rule ensures the meter is not applied to the 
wrong asset. Since the dealer serial number is correct, no action is needed by the 
dealer. Rejected data identified as internal errors is manually entered into the 
mainframe system for invoicing. 

[0029] Each rejected data record not identified as an internal error is considered to be 
a Dealer error. For example, validation rules reject any data record when a current 
meter reading is less than the previous meter reading found in the system. This 
validation rule identifies that an incorrect meter reading has been provided by the 
dealer. Rejected data identified as dealer errors and the reason for the error is 
transferred to an Excel-based meter correction worksheet. The meter correction 
worksheet is e-mailed, e.g., via web server 1 4, to the dealer with expectation that 
the dealer will review the errors and input corrections and comments to the 
worksheet. 

[0030] The dealer receives the worksheet, reviews the errors and inputs the 

corrections and comments directly to the worksheet. The dealer manually updates 
the OMD software with the corrections, and e-mails the updated meter correction 
worksheet back to system 1 2 for processing. 

[0031] Figure 3 is a block diagram of another embodiment of a meter data process. 
The process steps illustrated in block 100 and 1 02 typically are performed by a 
dealer, and the process steps illustrated in block 104 typically are performed by a 
financial institution that has purchased the equipment lease portion of the contract 
with the end user. If a dealer has not sold or contracted for the services identified 
in block 1 04, then such processing would be performed by the dealer rather than a 
separate entity. 

[0032] process illustrated in Figure 2 automates the reporting of meter data and 
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validation of the data. In addition, the validated data is stored in the mainframe in 
a format readily usable for billing purposes. Of course, additional processes can be 
used in combination with the process illustrated in Figure 2. In addition, correction 
of error data also can be automated to further facilitate more timely and accurate 
billing. One such automated process is illustrated in Figure 3. 

[0033] Referring now specifically to Figure 3, meter data is collected by the dealer and 
input into server 44. Using the OMD software, the dealer inputs meter data and 
runs a task in the OMD software application that generates an export file 
containing the meter data. The export file contains meter data, asset serial 
number, model number, meter reading date, an invoice number, an amount of the 
receivables, customer name, coverage begin date, coverage end date, and service 
credits. The dealer then copies the export file from the OMD environment into the 
Windows environment of personal computer 46. 

[0034] More specifically, once the export file is copied into computer 44, the dealer 
accesses system 12, e.g., via a web site. Access to system 1 2 is controlled, for 
example, using authorized user names and passwords. Once the dealer enters an 
authorized user name and password, the dealer then has access to server sub- 
system 1 2 and transmits the export file to the Oracle database. The data file 
format is validated by system 10 and the data fields are checked for null values. 
Once the data is accepted, a header record is created to identify the file sender and 
number of records. Also, once the data is accepted, the dealer receives 
confirmation, e.g., via the web site, such as: Your file was successfully transmitted. 
We received XX records in your file. Our Usage Billing System will be processing 
your file. If during that process any errors are encountered, we will contact you. 

[0035] A data validation routine is run by main frame 24 to validate each data record 
of each file. The routine uses the rules described above in connection with Figure 2 
to validate the data. Each data record that passes all validation rules is then 
processed in the main frame system for invoicing the lessee for the service 
payment 

[0036] 

An error correction process is then initiated. Specifically, data records that do 
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not meet any one of the validation rules are rejected, and an error identifier is 
associated with each data entry that violates a validation rule. That is, each data 
entry that violates a validation rule is flagged in the Oracle database and the 
reason for the reject is associated with the data record. 

[0037] Data records that have been rejected, however, still should be processed. Web- 
based administration screens allow personnel access to the rejected data records, 
and each rejected data record is reviewed to determine if the reject was caused by 
an internal error that is not caused by invalid dealer data. For example, validation 
rules reject any data record when a duplicate serial number is found in the system. 
This validation rule ensures the meter reading is not applied to the wrong asset. 
Since the dealer's serial number is correct, no action is needed by the dealer. The 
administrator identifies the correct account schedule and serial number to 
associate with each data record. Rejected data identified as being rejected due to 
internal errors is released by flagging in the Oracle database. 

[0038] Each rejected data record not identified as an internal error is considered to be 
a Dealer error. For example, validation rules reject any data record when a current 
meter reading is less than the previous meter reading found in the system. This 
validation rule indicates that an incorrect meter reading has been provided by the 
dealer. 

[0039] Rejected data identified as dealer errors is released by flagging in the Oracle 
database. Data records flagged as Dealer errors are released to the meter 
correction report which is accessible by the dealer via the Internet, e.g., a web site. 
Also, by referencing the header record for the data file, an e-mail notification is 
automatically sent to the dealer alerting the dealer that corrections are waiting for 
input. 

[0040] The dealer accesses the meter correction report in system 1 2 via, for example, 
a web site. Specifically, a home page is designated through which the dealer can 
log into system 1 2. Once logged into system 1 2 via the web site, the dealer can 
access the meter correction report. 
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[0041] The meter correction report lists all of the rejected data records, a brief 

explanation of the reason the record was rejected, a suggested list of possible 
corrective actions which the dealer may select, and the file name and date the 
record was sent. The dealer can download and print the report. Once the dealer 
has researched the rejected records, the dealer enters updated information and 
comments directly into the meter correction report. Once the dealer completes all 
data entry, the dealer selects a Send Corrections button to save the data to the 
Oracle database. 

[0042] Prior to exiting the application, the dealer is prompted as to whether the dealer 
wants to print the meter corrections report. The dealer can use the report to 
manually update the dealer OMD software with the corrections. The corrections 
that are saved to the Oracle database populate into the web-based administration 
screens used by personnel to review and release data records for processing. 

[0043] The processes described above facilitate ensuring that meter data is validated 
and in a format readily usable for billing purposes. Set forth below is a description 
of an exemplary process for using such stored data in a payables data process. 

[0044] More specifically, Figure 4 is a data flow diagram for a payables data process. 
The processes illustrated in block 1 50 typically are performed by the entity which 
purchased the leased equipment and assumed the obligation to bill the customer 
for usage based charges. The processes illustrated in block 1 52 typically are 
performed by an entity that has purchased the equipment lease usage payment. 
The processes illustrated in block 1 54 typically are performed by a customer. Of 
course, the processes illustrated in Figure 4 could be performed by any appropriate 
individual or entity, and the description of such processing as set forth herein is 
exemplary only. 

[0045] Referring specifically to Figure 4, once meter reading data records have been 
accepted for invoicing, the mainframe system creates invoices for the dealers 
service payments. Hard copies of the invoices are mailed to the customers. The 
customer receives the invoice and makes payment to the financing entity. The 
customer mails the payment directly to the financing entity. 
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[0046] The financing entity receives the customer payment and applies the cash to 
open receivables, which triggers opening payables to the dealer for service 
payments. Once customer payments have been applied and the payment is 
forwarded to the dealer for service payments due, then a mainframe application is 
run to create a payables data file. The file includes all of the payment information 
the dealer needs to apply cash to the open receivables, e.g., check number, check 
amount, payment detail by asset, service payment breakdown by base service and 
overage charges, dealer invoice number, bill to number and customer name. The 
payables file also includes a header record that identifies which data elements 
should be used by the OMD Task 1 Y to match the data in the payables data file to 
the dealer's payable data in the OMD software. The payables data file is 
electronically transmitted to the Oracle database. 

[0047] The payables data file represents payment information associated with the 
checks sent to the dealers. The checks are generated, for example, weekly. A 
percentage, e.g., 3%, of the checks may require modification to the payment 
information associated with the check. Therefore, the payment data is modified 
prior to releasing it to the dealer. Web-based administration screens allow 
personnel access to the payment information. 

[0048] The administration screens allow personnel to access the payment information, 
review each data record, flag each record for release, or hold and then edit any of 
the held records prior to releasing. Once released, the data records are made 
available to populate the payables report. The payables report is used by each 
dealer to apply cash to open receivables in the OMD software. 

[0049] The dealer accesses the payables report via the web site. Once logged on to the 
web site, the dealer can access the payables report to view payables information 
associated with the check received. The payables report allows the dealer to view 
information by invoice number, customer name, or date range. The dealer also can 
download the payables data file. The payables data file also is electronically 
transferred to the dealer computer. 

[0050] The dea | er uses the p a y a b| es d ata to apply cash against open receivables 
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within the OMD software. For example, the OMD software includes a program, i.e., 
Task 1 Y, which automatically applies the cash. The OMD program attempts to 
match the dealer open receivable against the data provided in the file. The 
program is able to match on either one or a combination of the following data 
fields: "Serial number/Model number", "Bill To", "Ship To", "Invoice Number", 
"Invoice Date" and/or "Coverage Begin Date". The payables file downloaded from 
the web site includes a header record that directs the OMD Task 1 Y to match the 
payables data to the Dealers open receivables by "Bill To" and "Invoice Number". 
For data records that do not match, the OMD program provides information as to 
why the record was not matched. 

[0051] The payables data process facilitates issuance of invoices, and well as payment 
of invoices and applying such payments to open accounts receivable to reconcile 
billing records. Such process also facilitates ensuring that the appropriate 
payments are received by the various entities involved including the financial 
institutions as well as the dealers. 

[0052] While the invention has been described in terms of various specific 

embodiments, those skilled in the art will recognize that the invention can be 
practiced with modification within the spirit and scope of the claims. 
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